home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001256_daemon _Sat Jun 12 01:47:04 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  5KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA05269; Sat, 12 Jun 93 01:47:06 MET DST
  3. Return-Path: <janssen@parc.xerox.com>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA05264; Sat, 12 Jun 93 01:47:04 MET DST
  6. Received: from alpha.Xerox.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA07990; Sat, 12 Jun 1993 02:09:03 +0200
  8. Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11714>; Fri, 11 Jun 1993 17:08:55 PDT
  9. Received: by holmes.parc.xerox.com id <16134>; Fri, 11 Jun 1993 17:08:44 -0700
  10. Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
  11.           via MS.5.6.holmes.parc.xerox.com.sun4_41;
  12.           Fri, 11 Jun 1993 17:08:36 -0700 (PDT)
  13. Message-Id: <0g6Fu48B0KGW5geexr@holmes.parc.xerox.com>
  14. Date:     Fri, 11 Jun 1993 17:08:36 PDT
  15. Sender: Bill Janssen <janssen@parc.xerox.com>
  16. From: Bill Janssen <janssen@parc.xerox.com>
  17. To: timbl@www3.cern.ch
  18. Subject: CR not stripped properly on FTP transfers
  19. Cc: www-talk@nxoc01.cern.ch
  20.  
  21. OK, I think I see the problem.
  22.  
  23. 1)  HTFTP.c always uses ASCII mode FTP transfers.
  24.  
  25. 2)  In ASCII mode transfers of UNIX source documents, most UNIX ftp
  26. servers always put a CR before every LF.
  27.  
  28. [Note:  It's not clear under what conditions this *should* be done (On
  29. UNIX, every file is in some sense a binary file, interpretable only by
  30. an "understanding" program.  On other system, say VMS, the notion of
  31. "line" is in the file system for line-oriented files, and VMS FTP
  32. servers might choose, for non-line-oriented files being transmitted in
  33. ASCII mode, not to put CR before every line feed, but just at the end of
  34. every block, or not at all (after all, no "lines").).  The RFC for FTP
  35. says:
  36.  
  37. >         3.1.1.1.  ASCII TYPE
  38.  
  39. >             This is the default type and must be accepted by all FTP
  40. >             implementations.  It is intended primarily for the transfer
  41. >             of text files, except when both hosts would find the EBCDIC
  42. >             type more convenient.
  43.  
  44. >             The sender converts the data from an internal character
  45. >             representation to the standard 8-bit NVT-ASCII
  46. >             representation (see the Telnet specification).  The receiver
  47. >             will convert the data from the standard form to his own
  48. >             internal form.
  49.  
  50. >             In accordance with the NVT standard, the <CRLF> sequence
  51. >             should be used where necessary to denote the end of a line
  52. >             of text.  (See the discussion of file structure at the end
  53. >             of the Section on Data Representation and Storage.)
  54.  
  55. Since HTFTP never seems to transmit the STRU command, we assume that the
  56. file is transferred with structure "file-structure", which means,
  57. according to the RFC, that
  58.  
  59. >          3.1.2.1.  FILE STRUCTURE
  60.  
  61. >             File structure is the default to be assumed if the STRUcture
  62. >             command has not been used.
  63.  
  64. >             In file-structure there is no internal structure and the
  65. >             file is considered to be a continuous sequence of data
  66. >             bytes.
  67.  
  68. The TELNET RFC (which I believe is still 854; does something later
  69. obsolete it?) says about CR and LF,
  70.  
  71. >       Therefore, the sequence "CR LF" must be treated as a single "new
  72. >       line" character and used whenever their combined action is
  73. >       intended; the sequence "CR NUL" must be used where a carriage
  74. >       return alone is actually desired; and the CR character must be
  75.       avoided in other contexts.
  76.  
  77. So my reading would be that for UNIX files being transmitted with mode =
  78. "ASCII" and structure = "file-structure", the sender would have to put a
  79. NUL character after every CR, and should *not* put a CR in front of any
  80. LF, since there really are no "lines of text" in the UNIX file system.
  81.  
  82. This is probably why I'm not a net.wizard.
  83.  
  84. end Note]
  85.  
  86. 3)  WWW should then change CR-LF pairs to simple LF, but there is no
  87. routine which does this (HTCopyNoCR discards *all* CR's, which is OK for
  88. text documents (usually), but not for binary documents like tar files). 
  89. There's also no easy way in HTFormat.c to "think" about this, because
  90. it's a characteristic of the input stream, not of the input format
  91. (which is something more like "www/mime").
  92.  
  93. 4)  Because of this, "binary" documents are copied to the output with
  94. HTCopy, which does not strip any characters, even the ones which
  95. *should* be stripped.
  96.  
  97. So the problem is that the actions of the FTP protocol are not being
  98. reversed anywhere.  This particular trait is a characteristic of the
  99. transfer protocol being used, not of the document's input format or of
  100. the transfer-encoding.  Seems like the right thing to do is to remove
  101. the simple file_number model used in HTFormat.c, and replace it with an
  102. input stream, which could then be specialized as necessary to remove the
  103. actions of the transfer protocol, if necessary.  Another possibility
  104. would be to always use BINARY mode transfers in the FTP module (since
  105. that's what HTFormat.c seems to expect), and add CR if necessary in the
  106. WWW library.  Perhaps both of these should be implemented.
  107.  
  108. Bill